# Monitoring the Power Platform: Azure DevOps - Notifications and Service Hooks
## Summary
[DevOps](https://azure.microsoft.com/en-us/overview/what-is-devops/) has become more and more ingrained into our **Power Platform** project lifecycle. Work item tracking and feedback tools for teamwork. Continuous integration and delivery for code changes and solution deployments. Automated testing for assurance, compliance and governance considerations. Microsoft's tool, **[Azure DevOps](https://azure.microsoft.com/en-us/overview/what-is-devops/#culture)** provides native capabilities to plan, work, collaborate and deliver. Each step along the way in our [**Power Platform DevOps** journey](https://docs.microsoft.com/en-us/power-platform/alm/devops-build-tools) can be tracked and monitored which will be the primary objective of this article.
This article will focus on feedback, specifically from events that happen with **Azure DevOps**. We will first look at subscription setup and notifications to team members and interested parties. From there we will dive deeper into feedback events, how they work, how they can be filtered and delivered. Finally we will review a real world example utilizing service hooks, **Power Automate** and **Microsoft Teams**.
## Sources
Sources of **Azure DevOps** events that impact our delivery can come from virtually any area of the platform including work items, pipelines, source control, testing and artifact delivery. For [practically any event within **Azure DevOps**](https://docs.microsoft.com/en-us/azure/devops/notifications/oob-supported-event-types?view=azure-devops), such as completed work items, executed builds or delivered releases, we can setup notifications. Service hooks and notification subscriptions can be configured to allow real time reporting of events to external parties and systems allowing for us to stay in a state of continuous communication and collaboration.
## Subscriptions and Notifications
[**Notifications**](https://docs.microsoft.com/en-us/azure/devops/notifications/about-notifications?view=azure-devops) help team members stay informed about completed events within with **Azure DevOps**. These events are similar to service hook events except the **primary delivery mechanism is through email**. Notifications are based on subscriptions configured with the notifications section of the Project Settings. If the subscription's filter conditions are met by the event, a notification is generated. **A notification is generated for every subscription/event match.**
### Setting up Subscriptions
**[Subscriptions](https://docs.microsoft.com/en-us/azure/devops/notifications/manage-organization-notifications?view=azure-devops)** can be used to notify stakeholders and downstream sources of events [each time an event occurs](https://docs.microsoft.com/en-us/azure/devops/notifications/oob-built-in-notifications?view=azure-devops). This allows for team members to **automatically send notifications while performing day to day tasks** such as updating work items and checking in changes, **without manual intervention**. Below is an example of setting up a new subscription for work items.
Once configured, we can now **notify the team based on any work item field such as Iteration or Area Path**. The below image shows filtering to the *University Support Team* **Area Path**. This subscription will **send an email once any work item is closed** by the team.
[**Subscriptions**](https://docs.microsoft.com/en-us/azure/devops/notifications/concepts-events-and-notifications?view=azure-devops) can also be used for updates to the code base, helpful for when we need to **track changes and requests for peer reviews**. If Git is used for source control management, **each commit and pull request can be subscribed to.**
**Builds and Releases** can also be setup to deliver notifications based on their lifecycle events. For builds, subscriptions can be based on build completions or when they fail.
Releases can notify stakeholders on completion, on pending approvals and when manual intervention is needed.
Example email of a **pending deployment approval**:
Each notification can be scoped to a particular role or stakeholder which can help control clutter. The below image shows how the "***Deliver to***" field can be fine tuned to team or project members or even custom email addresses distribution lists.
The final option is to use SOAP to deliver these same messages via an API call. I haven't used this particular feature and I would recommend if interested in API integration to continue reading. **Below we will cover using Service Hooks for notifications.**
#### How are recipients determined?
[Email notifications can be scoped to custom personal addresses, teams and groups](https://docs.microsoft.com/en-us/azure/devops/notifications/concepts-email-recipients?view=azure-devops). As the initiator of a particular event, you can void being sent a notification by checking the "***Skip initiator***" option. I would set this option for items like work items but consider leaving on for pull requests or builds.
## Service Hooks
[**Service Hooks**](https://docs.microsoft.com/en-us/azure/devops/service-hooks/overview?view=azure-devops) are a great way of staying informed and informing others of events happening within **Azure DevOps** allowing you to be freed up to focus on other things. Examples include **pushing notifications to your teams' mobile devices**, **notifying team members on Microsoft Teams** or even **invoking Microsoft Power Automate flows**. Services can include other build and release platforms (i.e. Jenkins and Slack), Collaboration tools like **Office 365**, Customer Support interfaces like **UserVoice** and Integration services (**Azure Service Bus, Azure Storage, Zapier**, etc).
When an **event** occurs in **Azure DevOps Services or TFS**, its content is compared with every **subscription** of that event type. If the subscription's filter conditions are met by the event, a notification is generated. **A notification is generated for every subscription/event match.** In the example below, the service hook is configured to send a consumer the "***Build Completed***" event.
Release events are also available, allowing teams to track when a deployment starts and when each deployment stage state has changed. In a following article, we will discuss the importance of deployment stages can be for collaboration across multiple teams during a deployment. Below is an example of the "***Release deployment started***" trigger.
An example of the "***Run Stage State Changed***" trigger.
### Filtering for Specific Events
Filters include the ability to scope to a particular type of event but also in some cases statuses. For instance consider the build completed event. This can be filtered a specific pipeline for unpacking and committing **Power Apps** solutions to source. If successful we may not necessary care but on a failure we want to understand and automate a potential fix. By filtering on the Failed status of our **Power Apps** solution pipeline we can send these events to 3rd party communication systems or messaging systems like **Azure Service Bus**.
#### Example: Azure Service Bus Messages for Release Start and Completion
Here's an example of **Azure Service Bus** and the different locations events can be sent to such as **Notification Hub, Queues and Topics**. Each event type such as sending failed events can be sent to queues and topics allowing for integrations between external systems.
Once configured, the service hook will deliver a message to the **Azure Service Bus queue** based on the filtered event. The below images show an example of messages from a release pipeline start taken using [Azure Service Bus Explorer](https://github.com/paolosalvatori/ServiceBusExplorer). ***NOTE: Since writing this, the [Azure Portal has a new feature](https://docs.microsoft.com/en-us/azure/service-bus-messaging/explorer) to allow for peeking into queue messages.***
Notice the event type "***ms.vss-release.deplyment-started-event***" signaling the start of the release.
For completed releases, the event type "***ms.vss-release.deplyment-completed-event***" will be shown:
As highlighted above, the ***EventType*** field contains what event happened and can help identify and differentiate between events. Included in the release is a markdown message that can be used as part of our release notes. The ***createdDate*** for both can help determine the length of the deployment of our **Power Platform** artifacts.
### Considerations for Service Hooks
**Service Hooks**, like all services within **Azure DevOps** can be altered [using the **Azure DevOps REST API**](https://community.dynamics.com/crm/b/crminthefield/posts/monitoring-the-power-platform-azure-devops---using-the-rest-api-to-monitor-pipelines). [The ability to test notifications](https://docs.microsoft.com/en-us/rest/api/azure/devops/hooks/notifications/create?view=azure-devops-rest-5.1) will be helpful as you explore how events are triggers and the payload associated with each event.
## Web Hooks
**Web Hooks**, used by Service Hooks, allow for publishing messages and events to any type of service interested in the **Power Apps** DevOps process. **Azure DevOps** provides the ability to integrate with a [generic web hook](https://docs.microsoft.com/en-us/azure/devops/service-hooks/services/webhooks?view=azure-devops) that may not be available in the **Visual Studio Marketplace**. Web Hooks can be used to deliver messages to low code solutions such as **Power Automate** or **Azure Logic Apps**. They can also be used for development platforms such as **Azure Functions**, [allowing for usage of the Azure DevOps SDK](https://github.com/aliyoussefi/MonitoringPowerPlatform/tree/master/Samples/DevOps/ReleaseNotesGenerator) as well as other toolkits and frameworks.
### Creating a Web Hook
Creating a web hook requires a subscription for events to be sent to as shown in the diagram above. Messages can be consumed by listeners interested in a particular event or topic. This architectural pattern known as Publish and Subscribe (Pub/Sub) allows **Azure DevOps** to publish many types of messages and for subscribers to only be notified of events they are concerned about.
### Example: Web Hooks in Action
A real world example of using a web hook came up when I needed to come up with a solution for creating a notification that a build pipeline was started to migrate a **Dynamics 365** solution to another environment for testing. Typically, I would first look to notifications as detailed above. However in this particular scenario, I needed to provide additional detail from other platforms that are used for work item tracking outside of **Azure DevOps**. The solution needed to provide an update to the development team that their work was being promoted and the ability to track the work items.
In this scenario, the solution I settled on four services: **Azure DevOps Web Hooks**, **Power Automate Flows**, **[Microsoft Adaptive Cards](https://adaptivecards.io/)** and **Microsoft Teams**. **Azure DevOps Web Hooks** were used to fire an event to **Power Automate,** which was listening for an HTTP request. **Power Automate** would then query the 3rd party work item tracking service for detailed on work items. From there, **Power Automate** would create an **Adaptive Card**. The **Adaptive Card** was designed to provide direct links back to the 3rd part work item service and to the **Azure DevOps Build**, currently in progress. Finally, the **Adaptive Card** was sent to a **Microsoft Teams Channel** for distribution.
For sample code and further documentation, please [refer to this link](https://github.com/aliyoussefi/MonitoringPowerPlatform/tree/master/Samples/DevOps/PowerAutomate).
## Next Steps
In this article we have the beginning stages of collecting and distributing feedback for our teams and stakeholders. Email notifications based on work item updates and code changes allow specific teams to quickly respond to changes. Service hooks allow for events to be sent to first and third party integrations. Web hooks allow for complete flexibility, delivering stateful messages to HTTP endpoint subscribers.
Continuing from here, [we will explore the Azure DevOps REST API and specific actions that can be useful for tracking changes](https://community.dynamics.com/crm/b/crminthefield/posts/monitoring-the-power-platform-azure-devops---using-the-rest-api-to-monitor-pipelines). [For collaboration, we will review Chat Bots and integrations with Microsoft Teams](https://community.dynamics.com/crm/b/crminthefield/posts/monitoring-the-power-platform-azure-devops---orchestrating-deployments-and-automating-release-notes). For deployment tracking, we will dive into build and release events and opportunities to analyze for greater insights into trends.
If you are interested in learning more about [**specialized guidance and training** for monitoring or other areas of the Power Platform](https://community.dynamics.com/crm/b/crminthefield/posts/pfe-dynamics-365-service-offerings), which includes a [monitoring workshop](https://community.dynamics.com/cfs-file/__key/communityserver-blogs-components-weblogfiles/00-00-00-17-38/WorkshopPLUS-_2D00_-Dynamics-365-Customer-Engagement-Monitoring-with-Application-lnsights-1-Day-with-Lab_2D00_FA5D599F_2D00_20E4_2D00_4087_2D00_A713_2D00_39FBD14DF7E5.pdf), please contact your **Technical Account Manager** or **Microsoft representative** for further details.
Your feedback is **extremely valuable** so please leave a comment below and I'll be happy to help where I can! Also, if you find any inconsistencies, omissions or have suggestions, [please go here to submit a new issue](https://github.com/aliyoussefi/MonitoringPowerPlatform/issues).
## Index
[Monitoring the Power Platform: Introduction and Index](https://community.dynamics.com/crm/b/crminthefield/posts/monitoring-the-power-platform-introduction)